FYI that repo is only archived because it moved to SourceHut. The crate is still developed and maintained. That being said, I'm happy if it can come under the rust-postgres umbrella.

@jbg thank you so much! I wasn't sure what has happened to it, and some of us got really concerned when we saw that your repo was archived without any notes, while crates.io still pointed to it. Could you maybe unarchive it, put some big notification at the top with the links to the new location, and re-archive it?

I am not familiar with the sourcehut, and I tried to find it there, but it didn't come up with any results.

I am all for collaborative software development -- we tend to support software until our interest runs out, so ideally there should be a community behind each project rather than a single person - to prevent any kind of disaster or lack of interest from ruining an amazing project. I am not sure what @sfackler 's plans are for this project - I really hope we can all work on it together, perhaps starting an organization too? Regardless, you have done a great job maintaining it, so I wouldn't want to take it away from you, but please consider keeping it on github so that all other FOSS devs can easily participate.

Thanks!

There is a link at the top of the Github repo (at the right on desktop) to the Sourcehut repo.

I may just move back to Github given that hosting elsewhere causes this confusion 😬

Sorry for the delay - if @jbg's happy maintaining it externally then I think it'd probably be best to keep things as-is.

I'm ok either way, but one thing to note: we urgently need to implement all the tls compatibility with rustls - the upstream team seems to not want to have an easy path for us to upgrade from openssl to rustls, and thus we would have to do a considerable implementation of everything related to sqlmode=....

I think it would be best to implement this type of functionality in this project for higher visibility -- keeping postgresql-related things together is easier than trying to hunt for individual pieces. Of course if @jbg is ok with this transition?

@nyurik Can you clarify what functionality you are talking about when you say "all the tls compatibility with rustls"? Any kind of verification (or lack thereof) that you can implement with rustls, you can use tokio-postgres-rustls with. There is no need for any special support to be implemented in tokio-postgres-rustls or tokio-postgres, you just pass the appropriate ClientConfig to MakeRustlsConnect::new(). If you're having a specific problem, please open a related issue.

Ah, I see you already have. Linking to jbg/tokio-postgres-rustls#11 here for context and will continue the discussion there.

Given the lack of response to any of

• fix: Use correct digest for SCRAM channel binding jbg/tokio-postgres-rustls#14
• add support for rustls 0.22 jbg/tokio-postgres-rustls#15
• Change MakeTlsConnect impl Error to std::convert::Infallible jbg/tokio-postgres-rustls#16
• Upgrade ring to 0.17 jbg/tokio-postgres-rustls#17
  it may be time to revive this PR. It's maybe too soon now, but would be good to decide when it wouldn't be too soon. I reached out to @jbg a week ago asking if he'd like help maintaining tokio-postgres-rustls

I really think that tokio-postgres-rustls should be part of this repo, even if not maintained by @sfackler.

I've made a tokio-postgres-rustls release (apologies for the delay -- was moving countries!).

@jbg @sfackler is there any possibility this PR gets merged? Or just tokio-postgres-rustls will be maintained outside?

For colocated we can synchronously release tokio-postgres-rustls with tokio-postgres when any new minor/major version bump happens. And any breaking changes would be caught by the CI.

Given rustls' popularity, we should have a well maintained integration with rust-postgres. Reiterating #962 (comment), if @jbg is happy to maintain it then it's ok for us too. There are 3 pending PRs right now that make it look like it may not be getting much attention though.

As an alternative we could either take on maintenance, and in that case this PR would need to be updated to include all of the latest commits ¹, or the rustls org could.

Now that I look at it tokio-postgres-rustls is MIT, while our crates are MIT OR Apache-2.0, so we'd have to figure that out too if we were to merge their history into this repo.

tokio-postgres-rustls definitely seems to be unmaintained or at the very least maintained at a very slow pace. I just found the tokio-postgres-rustls-improved crate, which tries to solve the issue via a fork, but I thnk it would be much better to maintain it alongside this crate. Really hope the licensing difference does not block that

The license is not a problem, worse case scenario we keep it into a separate repo instead of this one. tokio-postgres-rustls-improved indeed seems the better client 👍.